External network-to-network interfaces are used where two heterogeneous networks interface with one another so as to transmit data between the two networks. Examples of heterogeneous networks that may interface with one another include packet-switched networks (TCP/IP networks) and optical transport subnetworks, which use different networking protocols and different domains, such as the electrical domain for the packet network and the optical domain for the optical transport subnetwork. In order for networks with different networking protocols, transport technologies, or management approaches to interface with one another, established interfacing protocols have been developed by industry, such as the External-Network-Network Interface (E-NNI) routing protocol based on the User Network Interface (UNI) [G.8080] routing architecture developed by the Optical Internetworking Forum, for example. Another example of an established routing protocol that may be used as an E-NNI protocol is OSPFv2 [RFC2328] with extensions for traffic engineering [RFC3630] and Generalized Multi-Protocol Labels Switching (GMPLS) [RFC 4202, RFC 4203]. Other E-NNI protocols include OIF E-NNI and IETF E-NNI, for example.
A common interfacing protocol, such as E-NNI, typically specifies a control domain and common signaling and routing protocols so that signaling and routing information can be exchanged between control domains of the interfacing networks. The common interfacing protocol essentially enables requesting and establishing dynamic connections and connection services across heterogeneous, multi-domain networks, such as service subnetworks and transport subnetworks, for example.
Service providers use service subnetworks to provide services to users, such service subnetworks are interfaced with a transport subnetwork, such as a long-haul network or a backbone network. The transport subnetworks carry user data or traffic over long distances to another service subnetwork where the user data or traffic is transferred either to or from. Service providers typically provide networking services directly to users via their respective service subnetwork, and network operators typically provide transport (e.g., backbone, core, or long-haul) network services to the service providers.
To increase efficiency and speed of services provided to users, service providers typically aim to create a logical network between one or more packet routers which are interconnected to one or more optical switches in the transport subnetwork. Further, service providers prefer to apply a typical router setup sequence to establish all connections in the network, which may cause compatibility issues in some cases, and may optimize service for a particular group of customers, and not necessarily for the transport subnetwork as a whole. In order to use a typical router set-up sequence, the service operators query information about the transport subnetwork, such information is created by the transport subnetwork operators and transmitted to the service providers, where such information is stored on one or more of the packet routers in the service subnetwork.
At the same time, transport subnetwork operators may wish to avoid providing internal transport subnetwork information for privacy, accounting or other business-related concerns.
For example, in existing network-to-network interfaces, an edge node (e.g., a packet router acting as a source or headend node in a service subnetwork) interfaces with a core node (e.g., an optical or other switch in a transport subnetwork) to obtain core transport subnetwork information, including transport subnetwork routing and available resource. This same information is likewise provided to a second edge node (e.g., a destination node is a service subnetwork). Next, the edge node locally computes a path for the data that is to be sent via the transport subnetwork, based on the transport subnetwork information provided to the edge node by the core node. After the edge node computes a path, the edge node sends a message including data for the core node to set up the computed path. The core node then stores the received service requests and relays the connection set up messages to the rest of the core nodes in the transport subnetwork. The core node also stores and maintains network state information indicative of the connections set up in the transport subnetwork by the edge nodes.
However, this approach relies on the support of compatible routing and signaling protocols between the service subnetwork and the core network. For example, the core node has to send data about the transport subnetwork to the edge node via Multi-Protocol Label Switching (MPLS) protocols such as Resource Reservation Protocol (RSVP), or Open Shortest Path First (OSPF). Further, edge nodes compute the path locally and typically lack enough information to initiate efficient layer-1 switching, which results in data being sent as IP-over-DWDM (or IP over dumb or statically provisioned pipes), which is inefficient in terms of transport subnetwork resource utilization. Finally, locally computing the path at the edge nodes requires the core nodes to store and maintain network “states” defined and initiated by the edge nodes, which is memory and computationally intensive and inefficient.